scheduled or physical events Users can 
manipulate objects in the simulation envi- 
ronment under programmatic control. 
Inputs to the scripting module are Ac- 
tions, Conditions, and the Script. Actions 
are arbitrary modifications to constructs 
such as Platform Objects (i.e. satellites), 
Sensor Objects (representing instruments 
or communication links), or AnalysisOb- 
j ects ( user-defined logical or numeric vari- 
ables). Examples of actions include 
changes to a satellite orbit ( v), changing 
a sensor-pointing direction, and the ma- 
nipulation of a numerical expression. 
Conditions represent the circumstances 
under which Actions are performed and 
can be couched in If-Then-Else logic, like 
performing v at specific times or adding 
to the spacecraft power only when it is 
being illuminated by the Sun. 

The SOAP script represents the entire 
set of conditions being considered over a 
specific time interval. The output of the 
scripting module is a series of events, 
which are changes to objects at specific 
times. AstheSOAP simulation clock runs 
forward, the scheduled events are per- 
formed. If the user sets the clock back in 
time, the events within that interval are 
automatically undone. 

This script offers an interface for 
defining scripts where the user does not 
have to remember the vocabulary of var- 
ious keywords. Actions can be captured 
by employing the same user interface 
that is used to define the objects them- 
selves. Conditions can be set to invoke 
Actions by selecting them from pull- 
down lists. U sers define the script by se- 
lecting from the pool of defined condi- 
tions. Many space systems have to react 
to arbitrary events that can occur from 
scheduling or from the environment. 
For example, an instrument may cease 
to draw power when the area that it is 
tasked to observe is not in view. The con- 
tingency of the planetary body blocking 
the line of sight is a condition upon 
which the power being drawn is set to 
zero. It remain sat zero until theobserva- 
tion objective is again in view. Comput- 
ing the total power drawn by the instru- 
ment over a period of days or weeks can 
now take such factors into considera- 
tion. What makes the architecture espe- 
cially powerful isthat the scripting mod- 
ule can look ahead and behind in 
simulation time, and thistemporal versa- 
tility can be leveraged in displays such as 
x-y plots. For example, a plot of a satel- 
lite's altitude as a function of time can 
take changes to the orbit into account. 

T his work was done by R obert C a rn right of 
Caltech and David Stodden, John Coggi, and 


Jim Paget of The Aerospace Corporation for 
NASA's Jet Propulsion Laboratory. 

T his software is available for commercial li- 
censing. Please contact Karina Edmonds of 
the California Institute of Technology at 
(626) 395-2322. Refer to NPO-45055. 


M XML-Based SHINE 
Knowledge Base 
Interchange Language 

The SH I N E Knowledge Base Inter- 
change Language software has been de- 
signed to mo re efficiently send new knowl- 
edge bases to spacecraft that have been 
embedded with the Spacecraft Health In- 
ference Engine (SHINE) tool. The inten- 
tion of the behavioral model is to capture 
most of the information generally associ- 
ated with a spacecraft functional model, 
while specifically addressing the needs of 
execution within SHINE and Livingstone. 
As such, it has some constructs that are 
based on one or the other. 

AsNASA/JPL autonomous science mis- 
sions go deeper and deeper into space, the 
collection of unexpected data becomes a 
problem. Data structures can easily be im- 
plemented in advance that can collect any 
kind of data; however, when it comes to 
processing the data into information and 
taking advantage of serendipitous science 
discovery, designing a fixed and efficient 
data structure becomes increasingly com- 
plex. This software defines and imple- 
ments a n ew ki n d of d ata str u ctu re th at can 
be used for representing information that 
is derived from serendipitous data discov- 
ery. It allows the run-time definition of ar- 
bitrarily complex structures that can adapt 
at run-time as the raw science data istrans- 
formed into information. 

This solves the problem decision 
trees can be prone to, namely how ex- 
pensive they can be to execute be- 
cause of the need to evaluate each 
non-leaf node and, based upon its 
truth, to either progress deeper into 
the structure or to examine an alter- 
native. This requires many machine 
cycles, which can negatively affect 
time-critical decisions. 

This software runs on a variety of dif- 
ferent platforms, including SUN, HP, 
Intel, Apple Macs, Flight Processors, etc. 
It can be distributed in either source 
code or binary code and requires a LISP 
compiler to run with a number, such 
compilers being either commercially 
available or found as shareware. The 
software has no specific memory require- 
ments and depends on the applications 
that are running in it. It is implemented 


as a library package and folds into what- 
ever environment is calling it. 

Currently, this software is a compo- 
nent of the Common Automation En- 
gine (CAE) that wasdeveloped for Deep 
Space Network (DSN). It has been in ac- 
tive use for over three years and has 
been installed in a shadow mode run- 
ning at Goldstone and DSN monitoring 
operations at J PL. 

T his work was done by M ark James, R yan 
Mackey, and Raffi Tikidjian of Caltech for 
NASA’s Jet Propulsion Laboratory. Further in- 
formation is contained in a TSP (see page 1). 

T his softwareis available for commercial li- 
censing. Please contact Karina Edmonds of 
the California institute of Technology at 
(626) 395-2322. Refer to NPO-44546. 


Core Technical Capability 
Laboratory Management 
System 

The Core Technical Capability Lab- 
oratory Management System (CT- 
CLMS) consists of dynamically gener- 
ated Web pages used to access a 
database containing detailed CTC lab 
data with the software hosted on a 
server that allows users to have remote 
access. Users log into the system with 
their KSC (or other domain) username 
and password. They are authenticated 
within that domain and their CTCLMS 
user privileges are then authenticated 
within the system. Based on the differ- 
ent user's privileges (roles), menu op- 
tions are displayed. CTCLMS users are 
assigned roles such asLab Member, Lab 
Manager, Natural Neighbor Integration 
Manager, Organizational Manager, 
CTC Program Manager, or Administra- 
tor. The role assigned determines the 
users' capabilities within the system. 
Users navigate the menu to view, edit, 
modify or delete laboratory and equip- 
ment data, generate financial and man- 
agerial reports, and perform other CT C 
lab-related functions and analyses. 

High availability and detail of lab data 
gives management insight into the needs 
and requirements of KSC CTC-funded 
labs. Comprehensive, quantitative, cur- 
rent data are available in one easily acces- 
sible location for Program Operating 
Plan (POP) development, justification of 
POP submittals, overguide requests, con- 
tract renewals, and phasing of mainte- 
nance and replacement requirements. 
Lab health is quantitatively understand- 
able. Financial and managerial reports 
are generated automatically from de- 
tailed data, and facilitate uniform com- 
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